Node20 requires glibc 2.28.

CentOS 7 ships with glibc 2.17. Therefore, once we upgrade julia-actions/setup-julia to Node20, self-hosted CentOS 7 runners won't be able to use new versions of the setup-julia action.

CentOS 7 will become end-of-life on June 30, 2024. Therefore, I think that we should wait until June 30 to upgrade setup-julia to Node20.

CentOS 8 ships with glibc 2.28. Therefore, self-hosted CentOS 8 runners will be able to run Node20.

@DilumAluthge Why not just release a new version? That's what setup-python did, for example. CentOS 7 users will stay on v1 and everyone else will move on

If node16 is EOL, shouldn't we move quickly to node20? Will those nodes stop working at some point?

All the other major actions bumped their major version to handle this. That seems like a good solution here too? Just make it julia-actions/setup-julia@v2?

Why not just release a new version?

Because then all bugfixes have to be backported to the old version v1, which is a nontrivial amount of work.

Will those nodes stop working at some point?

I haven't seen any announcement that GitHub-hosted runners will lose the ability to run node16 actions prior to June 30 of this year.

If node20 is faster, wouldn't it be nice for people who don't worry about CentOS 7 etc to be able to use it? v2 seems like a good choice.

EDIT: I see your point about backporting. What really depends on CentOS 7 in our ecosystem? I thought pretty much most package CI scripts use ubuntu-latest. I understand June 30 is not that far away...

we will start enforcing the use of Node20 rather than Node16 on the 13th of May.

Source: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

Personally, I'm not pleased that GitHub is forcing the upgrade a month and a half earlier than the CentOS 7 EOL. But unfortunately there's nothing that we can do.

So May 13 is when we'll need to switch to Node20. It'll probably be good to give ourselves a day or two of buffer, so let's plan on merging this PR on Monday, May 13, 2024 and making the new v2.0.0 release of this action on the same day.

I think you'll want to release 2.0 before the runner cut off date to give those who use this action some time to update their workflows to use 2.0 before nodejs 16 is removed. Otherwise they're stuck with a broken 1.0 for a bit.

Ah, that's fair. How much of a lead time do you think would make sense? Would one week be enough? Maybe two weeks?

Honestly? About two months ago would have been nice. Now is second best. Just 1-2 weeks before is super short. Thousands of projects need to adapt to this change.

Allowing for a smooth transition over multiple months like this is a major reason why GitHub actions can have multiple versions supported in parallel.

Why not do it right away? What will we gain with CentOS 7 support for another 6 weeks?

The version number bump will be done here: #228

Thanks @DilumAluthge!

I wonder if we should add a deprecation notice to @v1, perhaps even bundled with a check for the presence of a dependabot file and info on how to set it up?

Otherwise I imagine lots of people will never get newer versions as they've just copied workflows that included @v1 at some point.

Similarly, PkgTemplates.jl and other places that contain a CI template need to be updated.

(There's a reason why in the past we've tagged a few releases as non-breaking even if they were technically breaking on enterprise/self-hosted setups)

I imagine lots of people will never get newer versions as they've just copied workflows that included @v1 at some point.

Or from this repo's README 😄